【AWS Dev Day Tokyo 2019 セッションレポート】 Chaos Engineering 〜入門と実例〜

AWS DevDay Tokyo 2019

森亮介

2019.10.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Dev Day Tokyo 2019 のセッション　Chaos Engineering 〜入門と実例〜　に関してのレポートです。

登壇者

株式会社Cygames

和田明久様

アマゾンウェブサービスジャパン株式会社

畑史彦　様

セッション概要

Chaos Engineering と聞くと皆さんは何を思い浮かべますか？ Netflix 社の Chaos Monkey による VM のシャットダウンなどが有名かもしれませんが、これは Chaos Engineering のかなり初期から存在するツールの１つでしかありません。現在はそこからエコシステムが拡大し、インフラストラクチャ・レイヤではなくアプリケーション・レイヤで注入し故障をより精緻に制御する方法論やサービスメッシュ・レイヤへオフロードする仕組みなど、多様な発展を見せています。このセッションでは、これら Chaos Engineering の歴史やエコシステムを整理しご紹介するとともに、株式会社 Cygames の和田氏に、実際にオンラインゲーム開発の現場で Chaos Engineering を実践してきた事例と、AWS サービスを活用した Chaos Engineering への今後の取り組みについてお話いただきます。

前半パート ~ カオスエンジニアリングの進化と今

AutoScaling
アプリをモニタリングしリソース量を自動で調整する機能

実際にインスタンスを安心して停止できますか？

-> 自信があっても怖いよね

だったら本番環境でテストしようこれが幅広く実践されるようになってきている

これがカオスエンジニアリング

カオスエンジニアリングの歴史

2010.12.14

Netflixのブログ： AWSのクラウドを選択した４つの理由
2010.12.1６

Netflixのブログ： AWSを使って学んだ５つのレッスン

そのうちの１つ、障害を避ける最も良い方法は継続的に障害を起こさせること

カオスモンキー(インスタンスをランダムに停止)　というシステムを構築

故障しても正常に機能する能力を常にテストしないと、最も重要な時、予期しない機能停止が発生した場合に機能する可能性が低くなる -> オートスケールが設定されていれば自動で復旧できる
２０１１.06: 猿(モンキー)の仲間が増える

The Netflix Simian Army
2014.10: FIT Microservicesレベルでの障害注入

FIT: Failure Injection Testing

Request Contextというメタデータ情報を伝播させることで、ダウンストリームのコンポーネントなどの狙い澄ましたポイントに障害をおこさせる

猿たちとFITの違い

いくつかの猿は、設計上ワイルドすぎる。インスタンスを落としたり、レイテンシを追加するなど
- 猿：インフラレイヤを直接的に扱う（インスタンスを落とす、ネットワーク遅延を追加）
  作用範囲を特定の何かに限定しづらい
  
  影響範囲を小さくしづらい
- FIT: アプリケーションレイヤで情報を伝搬させ、アプリケーションレイヤの情報を判断(狙った範囲に限定的に)
  
  特定のUAのクライアントだけに障害を注入する。
  
  テストフラグのあるユーザー通信のみDBアクセスを遅延させる
2015.09: カオスエンジニアリングの5原則、リージョンの停止をシミュレートするKong

Principles of Chaos Engineering

「対象とするシステムが本番環境における不安定な状況に耐えることができる」という自信を構築するために該当システムにおいて実施する実験の規律

エンジニアリングとして立て付けを作る。業界全体でやっているんだということを示す
- システム全体を反映しビジネスのコアを表現するシンプルな指標を定める
  Netflixの場合はSPS（Start Per Second）：　動画の再生開始ボタンを押された回数。これは定常的なはず。
- 本番環境で実行する
- 自動化されていないとつらい
２０１７.07: ChAP 自動化と他ツールとの連携

ChAP (Chaos Automation Platform）

chap-chaos-automation-platform

CI/CDと統合する(Spinnakerと連携している)
- テストが想定以上の影響を与えた場合、やっぱり自動的に検知して停止させたい
2019.05: 実施の自動化と作成の自動化
2020.06: 書籍出版予定

前半パートまとめ

クラウドではサーバの故障率をさげることはできない
Netflixはカオスエンジニアリングのイノベーター

他の多数の組織で同様の取り組みはあった

AWS Gameday　とか　
Gremlin, OSS toolも登場している
- ChaosToolkit
- Awesome Chaos Engineering
- Serverless
- aws-lambda-chaos-injection

基本的な設計も重要

最低限の可用性設計ができていることが好ましい、特に本番で望むならね

後半パート

Chaosconfの紹介
登壇企業の統計を見てみると、 IT業界に限らない、マイクロサービスに限らない
サイゲームズでの取り組み
なぜやるのか？

システムは壊れる

色々な要素が引き金となる

障害は不可避(AWSでも大規模な障害はどこかしら発生)

内部でも

ほぼ毎日何かが起きている
運用作業の低減
障害により影響を与えるもの
- 機会、時間、顧客、ブランド信頼

これらを回避したい

アプローチのしかた

principlesをベースとした4step - chaos loop

-- step1: 定常状態

システムのふるまいを示す指標を用いて定常状態を定義

-- step2: 仮説構築

実験グループで継続する仮説を構築

-- step3: 故障発生

実際に起きうるイベントをシステムに負荷

インスタンス停止
ネットワーク遮断
CPU Usage 100%
手法
AWS API
Linuxコマンド（stressなど

-- step4: 仮説反証

通常と実験グループのシステム出力を振り返り反証をあげる

事例紹介
- ElastiCache Reboot
  - 障害の種を事前に発見、対策まで出来た1例
- 詳細はCygamesテックブログを
Next Action
- よりアグレッシブに実験をするために
  - プロダクションでの実施
  - オートメーション
  - 影響の最小化
影響の最小化を深掘り
- 時短、トラフィックコントロール、VM>コンテナ>APｐ
トラコンに着目
- canary deploymentを応用
安全のメカニズム
- ビジネスアワーに制限
- 異常なインパクトを検知したら自動停止
- 実験トラフィックのサワー等は全体の5%未満
- failover
AWSでトラフィックを制御するには
- Route53
- Lambda
- AppMesh
- ALB
- 本番で実施するためには必須
  - ユーザにクリティカルなインパクトを与えない